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Preface 

This  standard  is  based  on  a  document1  presented  at  the  47th  Annual  International 
Telemetering  Conference.  The  original  document  contained  an  overview  of  XML  modeling  with 
some  initial  guidelines.  In  response  to  RCC  task  TG-124,  the  document  was  expanded  to 
establish  guidelines  that  allow  multiple  schemas  to  be  used  in  a  mix-and-match  fashion,  identify 
best  practices,  and  create  a  standard  look  and  feel. 

This  standard  was  prepared  by  the  Data  Multiplex  Committee  of  the  Telemetry  Group, 
Range  Commanders  Council.  The  XML  Style  Guide  defines  rules  and  guidelines  for  the 
development  of  modular  XML  schemas  across  the  suite  of  schemas  supported  by  the  RCC 
(currently  TMATS,  MDL,  IHAL,  and  DDML).  The  XML  Style  Guide  is  a  common  design 
reference  for  use  by  organizations  that  produce  XML  schemas,  by  ranges  that  receive  XML 
instance  documents  that  conform  to  the  schemas,  and  by  vendors  who  incorporate  XML  instance 
documents  into  their  telemetry  processing  systems.  The  use  of  this  style  guide  will  ensure  that 
all  T&E  XML  schema  standards  share  common  design  principles  and  a  common  look  and  feel  in 
order  to  promote  understanding,  familiarity,  and  interoperability. 

The  RCC  gives  special  acknowledgement  for  production  of  this  document  to  the  TG  Data 
Multiplex  Committee.  Please  direct  any  questions  to  the  committee  point  of  contact  or  to  the 
RCC  Secretariat  as  shown  below. 

Telemetry  Group  Chairman:  Mr.  Jon  Morgan 

412  TW,  Edwards  AFB 

Bldg  1408  Room  5 

301  East  Yeager 

Edwards  AFB,  CA  93524 

Phone:  DSN  527-8942  Com  (661)  277-8942 

Fax:  DSN  527-8933  Com  (661)  277  8933 

email  jon.morgan.2.ctr@us.af.mil 

Secretariat,  Range  Commanders  Council 
ATTN:  TEDT - WS-RCC 
1510  Headquarters  Avenue 

White  Sands  Missile  Range,  New  Mexico  88002-5 110 
Phone:  DSN  258-1107  Com  (575)  678-1107 

Fax:  DSN  258-7519  Com  (575)  678-7519 

email  usarmy.wsmr.atec.list.rcc@mail.mil 


1  Darr,  Tim,  John  Hamilton,  Ronald  Fernandes,  and  Charles  H.  Jones.  “Design  Considerations  for  XML-Based 
T&E  Standards.”  Paper  presented  during  47th  Annual  International  Telemetering  Conference,  Las  Vegas,  NV.  24- 
27  October  2011. 
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1.  Introduction 

The  next  generation  of  telemetry  systems  will  rely  heavily  on  extensible  markup 
language  (XML)-based  standards.  Multiple  standards  are  currently  being  developed  and 
reviewed  by  the  Test  and  Evaluation  (T&E)  community.  This  document  describes  XML  style 
guidelines  to  enable  the  development  of  modular  XML  schemas,  which  enables  the  ability  to 
“mix  and  match”  schema  type,  attribute,  and  element  definitions  from  different  schemas  to 
facilitate  reuse  and  interoperability  and  to  use  only  parts  of  a  schema  that  are  needed.  For 
example,  this  will  enable  the  reuse  of  common  schema  structures  such  as  a  common  units 
schema.  In  addition,  these  guidelines  ensure  that  all  T&E  XML  standards  share  common  design 
principles  and  a  common  look  and  feel  to  promote  understanding,  familiarity,  and 
interoperability. 

Existing  T&E  standards  (metadata  description  language  [MDL]2,  Telemetry  Attributes 
Transfer  Standard  [TMATS]  and  data  display  markup  language  [DDML]3,  instrumentation 
hardware  abstraction  language  [IHAL]4)  cover  a  unique  scope  and  define  ways  to  describe 
several  important  T&E  concepts.  Ideally,  future  T&E  systems  and  sub-systems  will  make  use  of 
concepts  from  several  of  these  standards,  combining  portions  of  each  standard  that  are  relevant 
to  the  given  sub-system.  For  example,  a  telemetry  ground  station  may  need  to  leverage  concepts 
related  to  measurements  (MDL),  measurement  packaging  (MDL  and  TMATS  XML),  and  data 
display  (DDML).  Similarly,  an  instrumentation  engineer’s  system  will  need  to  make  use  of 
concepts  related  to  instrumentation  hardware  (IHAL),  measurements  (MDL),  and  the 
relationships  between  instrumentation  and  measurements. 

In  the  sections  that  follow,  we  provide  a  short  introduction  to  XML  for  those  that  are  not 
familiar  with  it,  and  then  describe  XML  schema  design  guidelines  that  will  enable  the  sharing  of 
XML  standards  in  existing  and  new  standards.  We  illustrate  the  application  of  these  guidelines 
using  existing  XML  schemas. 

Our  intent  is  not  to  criticize  the  design  of  any  existing  standard.  Rather,  our  purpose  is 
threefold:  (1)  to  document  a  common  style  for  all  IRIG  106  XML  standards  to  promote 
consistency;  (2)  to  highlight  some  common  design  practices  that  inhibit  the  integration  and  reuse 
of  existing  standards  into  new  standards;  and  (3)  to  show  alternative  design  practices  that 
alleviate  these  issues.  The  XML  schema  design  practices  that  prevent  integration  and  reuse  of 
existing  standards  include  the  following. 

•  Duplication  of  identical  or  nearly  identical  structures.  It  is  not  uncommon  to  repeat  the 
same  structure  over  and  over  again  in  the  XML  schema.  It  is  sometimes  easier  to  copy 
and  paste  structures  instead  of  taking  the  time  to  design  a  proper  schema. 


2  Moore,  Michael  S.,  Jeremy  C.  Price,  Andrew  R.  Cormier,  and  William  A.  Malatesta.  “Metadata  description 
language:  The  iNET  metadata  standard  language.”  Paper  presented  during  45th  Annual  International  Telemetering 
Conference,  Las  Vegas,  NV.  26-29  October  2009. 

3  Range  Commanders  Council.  “Telemetry  Attributes  Transfer  Standard,”  in  Telemetry  Standards.  IRIG  106-15. 
June  2015.  May  be  superseded  by  update.  Retrieved  22  July  2015.  Available  at 
http://www.wsrm.armv.mil/RCCsite/Documents/106-15  Telemetry  Standards/Chapter9.pdf. 

4  Hamilton,  John,  Ronald  Fernandes,  Paul  Koola,  and  Charles  H.  Jones.  “An  overview  of  an  instrumentation 
hardware  abstraction  language.”  Paper  presented  during  42nd  Annual  International  Telemetering  Conference,  San 
Diego,  CA.  23-26  October  2006. 
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•  Duplication  of  elements.  Similar  to  the  previous  practice,  it  is  not  uncommon  to  define 
local  elements  that  refer  to  the  same  XML  structures. 

•  Monolithic  schemas.  It  is  very  common  to  design  an  XML  schema  as  a  single  monolithic 
file.  Decomposing  a  schema  into  logical  components  is  a  difficult  task  and  requires 
careful  design  and  thought  but  promotes  reusability. 

The  next  section  provides  an  overview  of  XML  and  XML  schemas  for  those  that  are  not 
familiar  with  these  technologies. 

2.  XML  Overview 

The  XML  standard  is  a  specification  produced  by  the  World  Wide  Web  Consortium 
(W3C),  whose  original  intent  was  to  provide  a  machine-readable  format  for  describing 
documents.5  Because  of  its  popularity,  wide  adoption,  and  prevalence  on  the  Internet,  its  use  has 
expanded  to  describe  arbitrary  data  structures  such  as  web  services  and  T&E  metadata.  The 
example  in  Figure  1  shows  a  portion  of  an  XML  document  (an  XML  snippet)  from  an  initial 
version  of  the  TMATS  XML  schema. 


<D :  Mea  s  u  r  eme  n  t  N  am  e  =  *TWFA  "> 

<D :  Parity >ID E < / D  :  Parity> 

<D: ParityTransferOrder >D</D: ParityTransferOrder:* 

<Dt MeasurementTransf erOrder >D</D: MeasurementTransf erOrder* 

<D; LocationType>WDFR</D: LocationType> 

<D:WordAndFrame> 

<D :  IDtounterWameX/D:  IDtounterName*- 
< D : Me  a  s  u  r eme  nt  Location* 

< D: Measurement Fragment s> 

<D : St  a  rtWo  r  d  > 1< / D : St  a  rtWo rd> 

<[>:  Wordlnterval>@</D:yordlnterval> 

<0:  StartFrame>K/D :  StartFrame> 

<D:  FrameInterval>K/D:  Frame Interval* 

<D:B itMa sk>FW</D:BitMask> 

</D: Measurement Fragment s> 

</D: Measurement Locations 
</D^yordAndFrame> 

</D : Measurements 

Figure  1.  Example  TMATS  XML  Snippet 

In  XML,  each  piece  of  data,  or  element,  is  surrounded  by  a  “tag”  such  as 
<D :  Measurement  and  <D:Parity>.  The  structure  of  an  XML  file  is  such  that  tags  can  be 
enclosed  in  other  tags  to  an  arbitrary  depth  (<D :  MeasurementLocation>  is  a  sub-element 
of  <D :  WordAndFrame>,  <D :  MeasurementFragments>  is  a  sub-element  of 
<D :  MeasurementLocation>,  etc.).  This  is  the  basic  idea  behind  the  structure  of  an  XML 
document. 

The  remainder  of  this  section  will  get  into  more  detail  about  the  specific  parts  of  an 
element  and  how  a  schema  defines  the  rules  for  a  specific  XML  document  type. 


5  World  Wide  Web  Consortium.  Extensible  Markup  Language  (XML)  1.0  (Fifth  Edition).  26  November  2008.  May 
be  superseded  by  update.  Retrieved  22  July  2015.  Available  at  http://www.w3.org/TR/REC-xml/. 
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2.1  Anatomy  of  an  XML  Element 

This  section  provides  a  brief  overview  of  the  structure  of  an  XML  element.  The 
component  parts  of  an  XML  element  are  identified  in  Figure  2.  Each  of  these  components  is 
defined  below  the  figure. 


r 


Start  Tag 

* 


1 


Element 


Element  name 
Namespace  Attribute 

I  1  1 

_(1  W  I 

<D: Measurement  Name="WFA"> 

<D: Parity >OE</D:Parity> 

<D:ParityTransferOrder>D</D:ParityTransferOrder> 

<D :  Measurement  TransferOrder>D</D:*ieasureirentT  ransf  erOrder> 
<D: LocationType>WDFR</D: LocationType> 

<D : WordAndFrame > 

<D:IDCounterNamex/D:  IDCounterName> 
<D:MeasurementLocation> 

<D:MeasuretnentFragments> 

<D : StartWord  >1</D : StartWord> 
<D:WordInterval>0</D:WordInterval> 

<D : StartFrame  >1</D : Start Frame  > 

<D: Framelnterval>l</D : Framelnterval> 
<D:BitMask>FW</D:BitMask> 
</D:MeasurementFr4gments> 

</D:MeasurementLoc^ti<bn> 

</0:WordAndFrame> 

</D: Measurement > 

1 _ _ |  Element 

value 


T 


End  Tag 


Figure  2.  Components  of  an  XML  Element 


•  Element:  “Element”  is  the  term  used  to  define  a  complete  unit  of  XML  information.  It 
begins  with  a  start  tag  and  ends  with  an  end  tag.  The  value  of  an  element  can  be  a  simple 
value  or  one  or  more  sub-elements  (children). 

•  Start  Tag:  The  start  tag  identifies  the  beginning  of  the  element  and  consists  of  the 
element’s  name  (and  possibly  a  namespace  and  attributes)  included  between  a  “<”  and  a 
“>”  symbol. 

•  End  Tag:  The  end  tag  identifies  the  end  of  the  element  and  looks  identical  to  the  start 
tag,  except  it  includes  a  “/”  (forward-slash)  after  the  “<”  symbol.  An  end  tag  does  not 
contain  attributes. 

•  Namespace:  The  namespace  is  optional  in  XML,  but  can  be  used  to  define  the  scope 
within  which  the  element  is  defined.  In  our  TMATS  example,  we  define  a  “d” 
namespace  (for  the  TMATS  D  Group)  and  make  all  of  the  D  Group  elements  members  of 
it. 

•  Element  name:  The  name  of  the  element  is  what  appears  in  the  start  and  end  tags  and  is 
what  actually  identifies  the  piece  of  information  being  defined. 
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•  Attribute:  Attributes  are  another  method  of  associating  information  with  an  XML 
element.  An  attribute  consists  of  a  name  followed  by  a  “=”  sign  followed  by  a  value 
enclosed  in  quotes.  There  is  currently  some  controversy  among  users  of  XML  as  to  when 
it  is  appropriate  to  use  an  attribute  instead  of  simply  adding  a  child  element  with  the  same 
name  and  value. 

•  Element  value:  The  value  of  the  element  is  everything  that  lies  between  the  start  tag  and 
the  end  tag.  The  value  can  EITHER  be  a  single  value  (e.g.  7,  “John”,  true,  etc.)  OR  a 
collection  of  one  or  more  sub-elements  (children). 

2.2  XML  Schemas 

An  XML  schema  is  a  design  document  used  to  describe  a  specific  language  that  is  based 
on  XML.  The  rules  for  formatting  proper  XML  are  very  simple  and  unrestricted.  A  schema 
defines  which  element  names  are  valid,  which  elements  can  have  which  children,  and  which 
values  are  valid  for  each  element.  Element  types  organize  XML  documents  by  defining  the 
allowed  structure  for  specific  groupings  of  elements. 

Even  though  an  XML  schema  is  itself  a  document,  it  is  usually  more  useful  to  view  the 
schema  as  a  diagram.  In  this  document,  we  use  diagrams  generated  by  the  XMLSpy®  tool.  In 
order  to  understand  these  diagrams,  we’ll  use  the  TMATS  XML  schema. 

An  example  schema  diagram  for  our  TMATS  example  is  shown  in  Figure  3.  The 
TMATS  example  shown  in  Figure  2  is  a  valid  XML  instance  document  that  conforms  to  this 
schema.  In  this  diagram,  XML  elements  appear  as  boxes  with  their  names  printed  inside. 
Attributes  appear  in  an  aptly  named  “attributes”  box.  For  both  attributes  and  elements,  a  solid 
border  indicates  that  it  is  required  while  a  broken  or  “dotted”  border  indicates  that  the  element  is 
optional.  You  will  notice,  for  example,  that  both  the  “TmatsCommon:TmatsVersion”  attribute 
and  the  <Parity>  sub-element  are  optional. 
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Figure  3.  Example  Schema  Diagram 


Sub-elements  are  connected  to  their  parents  with  lines  that  pass  through  a  special  symbol. 
Each  of  these  symbols  specifies  the  rules  for  how  the  elements  connected  to  the  right  side  of  it 

must  appear  in  an  instance  document.  A  “sequence”  symbol  (  “t'D3"  )  indicates  that  each  of  the 
child  elements  must  appear  in  an  instance  document  in  the  same  order  in  which  they  appear  in 


the  schema.  A  “choice”  symbol  ( 
exactly  one  of  the  child  elements. 


indicates  that  the  instance  document  must  contain 


The  XML  and  schema  concepts  presented  in  this  section  should  be  enough  to  understand 
all  of  the  examples  in  the  remainder  of  this  paper. 


2.3  Global  vs.  Local  Definitions 

Syntactically,  global  types  and  elements  are  defined  as  top-level  elements  in  XML. 
Local  types  and  elements  are  defined  as  sub-types  or  sub-elements  of  other  XML  components. 
Semantically,  global  types  and  elements  can  be  reused  throughout  the  rest  of  the  schema  while 
local  types  and  elements  can  only  be  used  in  their  local  context. 


3.  The  Case  for  Employing  These  Guidelines 

There  are  costs  for  not  employing  the  guidelines  described  in  this  paper  and  benefits  for 
employing  the  guidelines.  The  costs  include  the  following: 
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•  Difficulty  in  understanding  large  schemas; 

•  Large  schemas  increase  the  size  of  other  schemas  that  import  them; 

•  Changing  redundant  schema  components  in  multiple  places  is  time-consuming  and  can 

lead  to  errors. 

If  a  single,  large,  monolithic  schema  is  used,  it  can  be  difficult  for  a  human  to  understand 
the  schema.  This  is  especially  true  if  the  schema  contains  multiple  naturally  separable  logical 
components. 

Large  schemas  also  cause  problems  when  a  user  is  interested  in  using  a  subset  of  that 
schema  in  another  schema.  In  addition  to  the  problem  identified  above  in  understanding  the 
schema,  importing  (or  including)  a  large  schema  has  performance  costs.  The  entirety  of  the 
schema  must  be  imported  (or  included),  which  can  cause  problems  in  loading  the  schema  or 
downloading  the  schema  from  the  Internet. 

If  identical  structures  are  defined  multiple  times  and  the  user  needs  to  change  this 
structure  in  some  way,  the  user  must  search  for  all  instances  of  that  structure  and  make  the 
desired  changes.  This  takes  time,  and  if  the  user  misses  one  of  the  structures,  errors  will  be 
introduced  into  the  schema.  This  is  not  so  much  of  an  issue  for  a  structure  that  is  not  likely  to 
change,  but  for  evolving  structures,  this  could  be  a  major  issue. 

The  benefits  of  following  the  guidelines  include  the  following: 

•  Promotes  the  use  of  a  schema  in  other  schemas; 

•  Reduces  the  amount  of  time  needed  to  understand  a  schema; 

•  Reduces  the  time  needed  to  make  changes; 

•  Reduces  the  errors  when  changing  the  schema; 

•  Allows  composability,  which  is  the  ability  to  use  only  what  you  need. 

The  primary  benefit  of  these  guidelines  is  the  reuse  of  schema  structures  in  other 
schemas.  During  the  development  of  the  IHAL  standard,  it  was  necessary  to  represent 
measurement  units.  There  were  several  candidate  options:  develop  a  custom  representation  of 
units,  reuse  the  UnitsML  schema  standard  developed  by  the  National  Institute  of  Standards  and 
Technology6,  or  reuse  the  units  representation  that  is  part  of  MDL.  The  IHAL  team  chose  to 
reuse  the  MDL  representation  for  two  primary  reasons:  it  promotes  interoperability  between 
MDL  and  IHAL  and  it  reduces  the  amount  of  work  that  would  have  been  required  to  create  a 
new  units  representation. 

By  modularizing  a  schema,  it  becomes  easier  for  a  user  to  understand.  In  the  example 
given  previously,  by  separating  out  the  TMATS  R  group  schema,  it  would  be  easier  for  a  new 
user  of  the  schema  to  understand  not  only  the  R  group,  but  also  the  other  groups.  If  a  user  is 
interested  in  using  only  a  small  portion  of  a  schema,  such  as  the  TMATS  pulse  code  modulation 
(PCM)  measurement  structures,  a  modular  schema  provides  a  way  to  only  use  what  you  need. 


6  National  Institute  of  Standards  and  Technology.  Units  Markup  Language  home  page,  http://unitsml.nist.gov/. 
Accessed  14  July  2015. 
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By  defining  XML  types  and  elements  globally  and  reusing  these  structures  by  reference, 
maintenance  becomes  much  easier.  Changing  types  only  needs  to  be  done  in  one  place,  reducing 
the  time  to  make  changes.  Having  to  make  changes  to  only  one  structure  significantly  reduces 
the  potential  for  errors.  Extending  a  type  becomes  much  easier  as  well,  as  this  only  needs  to  be 
done  in  a  single  place. 

4.  Guidelines 

This  section  describes  the  guidelines  and  illustrates  their  use  via  examples  taken  from 
existing  T&E  schemas. 

4.1  Modularity 

The  following  guidelines  apply  to  schema  modularity.7Error!  Reference  source  not 

found. 

•  XML  schema  files  should  import  and  include  other  XML  schema  files  rather  than 
duplicating  these  elements  locally 

•  Schemas  should  be  specified  in  such  a  way  that  other  schemas  can  leverage  them. 

Details  are  provided  in  Section  4.5. 

Attempt  to  organize  the  schema  using  logical  modules  as  much  as  possible.  This 
promotes  composability  of  new  schemas  from  existing  schemas.  Figure  4  shows  the  TMATS 
schema  organized  into  modules  that  roughly  correspond  to  the  TMATS  groups  as  documented  in 
IRIG  106  Chapter  9.  The  dependencies  between  pairs  of  modular  sub-schemas  is  captured  using 
the  XML  import  relationship.  For  example,  the  top-level  Tmats.xsd  schema  depends  only  on  the 
TmatsGGroup.xsd  schema;  the  TmatsGGroup.xsd  depends  on  all  the  other  schemas  since  the  G 
Group  references  all  the  other  groups. 


7  David  Stephenson.  XML  Schema  Best  Practices.  December  2004.  Retrieved  15  July  2015.  Available  at 
http://xml.coverpages.org/HP-StephensonSchemaBestPractices.pdf. 
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Figure  4.  TMATS  Schema  Modularity 


Figure  5  shows  how  each  schema  is  imported  into  the  TMATS  G  Group  schema 
(TmatsGGroup.xsd  in  Figure  4)  using  the  XML  schema  import  statement.  Each  schema  import 
includes  the  location  of  the  schema  and  the  namespace  of  the  schema  that  is  being  imported.  The 
location  of  the  schema  can  be  on  the  local  file  system  or  a  remote  location  on  the  network.  For 
example,  the  location  of  the  TMATS  common  schema  (TmatsCommonTypes.xsd  in  Figure  4)  is 
TmatsCommonTypes.xsd  in  the  local  directory  and  the  namespace  is 

http://www.wsmr.army.mil/RCCsite/Documents/106-15_TelemetryStandards/TmatsCommon. 
The  namespace  is  a  unique  identifier  for  the  schema  as  a  whole.  The  namespace  of  a  given 
schema  is  defined  in  the  schema  itself.  The  important  point  is  that  the  namespace  that  is  in  the 
import  statement  must  match  the  namespaces  as  defined  in  the  schema. 


import 

Tmats  C  o  mono  nTy  pea  .xad 

na :  http  i/Zw  w  w  wsmr.  a  rmy.  mil/RC  Cs  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry%2  0  Sta  nd  a  rds/T mata  C  o  mmo  n 

import 

toc:TmatsBGroup.xsd 

na :  http:// w  w  w.  wa  mr.  a  rmy.  mil/RCCa  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry  %20  Sta  nd  a  rds/T mata  B 

import 

Id  c  T mats  CG  ro  u  p  .xad 

na :  http ://  w  w  w.  '.va  mr.  a  rmy.  mil/RC  Ca  ite/D  d  cu  me  nta/1 06-1 3_Te  le  metry  %2  0  Sta  nd  a  rds/T mata  C 

import 

Id  c:T  mataDG  ro  u  p.xad 

na  http:// w  w  w.  wsmr.  a  rmy.  mil/RCCa  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry1 %2  0  Sta  nd  a  rda/T mata 0 

import 

Id  c  :Ti  mata  HG  ro  u  p  .xad 

na :  http  7/ w  w  w.  wa  mr.  a  rmy.  mil/RCCa  ite/D  d  cu  me  nta/1 06-1 3_Te  le  metry  %2  0  Sta  nd  a  rda/T mata  H 

import 

Id  c  Tmats  MG  rou  p.xsd 

na :  http:// w  w  w.  wa  mr.  a  rmy.  mil/RCCa  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry' %2  0  Sta  nd  a  rds/T mata  M 

import 

Id  c  Tmats  PG  roup,  xad 

na  http :// w  w  w.  wa  mr.  a  rmy.  mil/RC  Ca  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry  %2  0  Sta  nd  a  rdajT  mata  P 

import 

Id  c  T  mats  RG  roup  .xad 

na :  http:// w  w  w.  wa  mr.  a  rmy.  mil/RC  Ca  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry1 %2  0  Sta  nd  a  rds/T  mata  R 

import 

Id  c  Tmats  SG  rou  p.xsd 

na :  http :// w  w  w.  wa  mr.  a  rmy.  mil/RC  Ca  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry1 %2  0  Sta  nd  a  rds/T  mata  S 

import 

Id  cTmatsTG  rou  p.xsd 

na :  http:// w  w  w.  wa  mr.  a  rmy.  mil/RCCa  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry1 %2  0  Sta  nd  a  rds/T mataT 

import 

Id  c  :Ti  mataVG  ro  u  p.xad 

na :  http :// w  w  w.  wsmr.  a  rmy.  mil/RCCa  ite/D  o  cu  me  nta/1 06-1 3_Te  le  metry  %2  0  Sta  nd  a  rda/T  mata  V 

■ts 

complexly  pe 

DatalinkType 

ann: 

-ts 

complexType 

Data  Source  Type 

ann: 

-Ss 

complexType 

Re  vi  s  i  o  nA  nd  U  p  dateType 

ann: 

■Ss 

complexlype 

Te  stl  nfo  rmatio  nTy  pe 

ann: 

■Ss 

co  mp  lexly  p  e 

Tmats 

an -TMATS  G-Group 

Figure  5.  TMATS  Schema  Modularity  Imports 
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Figure  6  shows  how  the  namespace  of  a  schema  is  defined  within  the  schema  itself,  using 
TMATS  as  an  example.  The  namespace  of  the  schema  is  defined  using  the  targetNamespace 
attribute  as  shown  in  the  figure.  Note  that  a  namespace  prefix  is  also  defined  for  the  TMATS 
schema  using  the  xmlns:Tmats  attribute.  Namespace  prefixes  are  described  below.  Best 
practices  for  using  namespaces  are  given  later  in  this  document. 


M  XML 

-H  jfs:schema 


=  xmlns:xs 

http://w  w  w.  w  3 .  d  rg/2  0  0 1  /X  M  LS  ch  e  rna 

=  xmlnsiTmafeG 

http://w  w w.  ws mr. □  rmy.  mil/RCCs  ite/D d  cu  me  nts/1 06-1 3 Te le metry %2 0  Sta  nd  a rds/T matsG 

=  xmlns:Tmafe 

http://w  w  w.  wsmr.  a  rmy.  mil/RCCs  Ite/D  d  cu  me  nts/1 06-1 3_Iele  metry  0  Sta  nd  a  rds/F mats 

!=  targetNamespace 

http://www.wsmr.army.mi1/RCCsite/Dacuments/1 06-1 3_Telemetny  %20  Sta  n  d  a  rd  sjT  mats 

=  e  le  me  ntForm  Default 

qualified 

=  attribute  Form  Default 

unqualified 

Figure  6.  Example  TMATS  Namespace  Definition 


Figure  7  shows  the  modular  IHAL  use  schema  that  is  composed  of  other  IHAL  schemas 
as  well  as  external  schemas  (XidML,  TMATS,  MDL).  The  IHAL  InstrumentUse.xsd  schema 
depends  on  types  defined  in  the  XidML  Network-Transport.xsd  schema,  the  TmatsRGroup.xsd 
and  TmatsPGroup.xsd  schemas,  and  the  MDL_vO_8_17.xsd  schema.  The  IHAL  schema 
depends  on  these  schema  modules  to  facilitate  interoperability,  which  guarantees  that  the  same 
information  is  represented  in  the  same  way  across  schemas.  The  IHAL 
CommonUnitsSchema.xsd  depends  on  the  MDL  units  schema  as  a  way  to  reuse  XML  schema 
implementations  already  defined  in  another  schema. 
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Name:  I  HAL  Use  Component  Disgrarr 


Figure  7.  IHAL  Use  Schema  Modularity  and  Composability 


4.2  Schema  Format 

Define  the  schema  according  to  the  W3C  XML  schema  definition  (XSD).8 

4.3  Naming  Conventions 

The  following  guidelines  apply  to  naming  conventions  (Stephenson  2004). 

•  Elements  and  attributes  should  be  named  consistently  using  camel  case. 

•  Simple  and  complex  types  should  be  named  consistently  using  Pascal  case. 

Enumerated  values  and  names  of  types,  elements,  and  attributes  should  be  concise  and 
informative  (less  than  25  characters).  Standard  abbreviations  (i.e.,  mA)  and  domain  acronyms 
(i.e.,  TandE)  should  be  used  with  careError!  Reference  source  not  found..9  Names  should  be 
Pascal  case  or  camel  case.  Pascal  case  is  a  naming  convention  in  which  the  first  letter  of  a  name 
and  the  first  letter  of  each  concatenated  word  is  capitalized  (i.e.,  MeasurementList, 


8  Gao,  Shudi,  C.  M.  Sperberg-McQueen,  and  Henry  S.  Thompson.  W3C  XML  Schema  Definition  Language  (XSD) 
1.1  Part  1:  Structures.  5  April  2012.  Retrieved  22  July  2015.  Available  at  http://www.w3.org/TR/xmlschemal  1-1. 

9  Google.  Google  XML  Document  Format  Style  Guide.  2008.  Retrieved  21  July  2015.  Available  at  https://google- 
stvleguide.googlecode.com/svn/trunk/xmlstvle.html. 


10 


XML  Style  Guide,  RCC  125-15,  July  2015 


RecorderType).10  Camel  case  is  a  naming  convention  in  which  the  first  letter  of  a  name  is  lower¬ 
case  and  the  first  letter  of  each  concatenated  word  is  capitalized  (i.e.,  signalConditioningCard, 
busAttributes)  (Google  2008). 

Names  of  element  types  must  only  contain  ASCII  letters  and  digits  and  should  start  with 
an  ASCII  letter.  Simple  and  complex  type  names  must  be  Pascal  case.  Figure  8  illustrates 
positive  and  negative  examples  of  this  convention.  In  Figure  8(a),  the  type  name  is  Pascal  case. 
In  Figure  8(b),  the  type  name  is  not  Pascal  case. 


Figure  8.  Application  of  Type  Naming  Convention 


Element  names  must  only  contain  ASCII  letters  and  digits  and  should  start  with  an  ASCII 
letter.  Elements  names  must  be  camel  case.  Figure  9  illustrates  positive  and  negative  examples 
of  this  convention.  In  Figure  9(a),  the  element  name  is  camel  case.  In  Figure  9(b),  the  type 
name  is  not  camel  case. 


Figure  9.  Application  of  Element  Naming  Convention 


Attribute  names  must  only  contain  ASCII  letters  and  digits  and  should  start  with  an 
ASCII  letter.  Element  and  attribute  names  must  be  camel  case.  Figure  10  illustrates  positive  and 
negative  examples  of  this  convention.  In  Figure  10(a),  the  attribute  name  is  camel  case.  In 
Figure  10(b),  the  attribute  name  is  not  camel  case. 


10  Microsoft  Developer  Network.  Capitalization  Styles,  n.d.  Retrieved  21  July  2015.  Available  at 
https://msdn.microsoft.com/en-us/librarv/x2dbvw72(v=vs.7 1  l.aspx. 
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(a)  Correct  application  of  attribute  naming  guideline  (b)  Incorrect  application  of  attribute  naming  guideline 


Figure  10.  Application  of  Attribute  Naming  Convention 


Enumerated  values  must  only  contain  ASCII  letters,  digits,  and  whitespace  and  should 
start  with  an  ASCII  letter  or  digit. 


4.4  Namespaces 

The  following  is  a  summary  of  the  best  practices  for  using  namespaces  (Stephenson 

2004). 

•  A  target  namespace  shall  always  be  specified  for  a  schema. 

•  The  target  namespace  and  the  schema  namespace  shall  be  mapped  to  prefixes. 

•  A  default  namespace  shall  not  be  used. 

•  Element  names  shall  always  be  qualified. 

•  Attribute  names  shall  not  be  qualified. 

The  XML  namespaces  are  used  to  uniquely  identify  the  schema  types  and  elements 
within  an  XML  schema  to  avoid  name  conflicts.  As  mentioned  in  a  previous  section,  the 
targetNamespace  attribute  in  a  schema  definition  defines  the  uniform  resource  identifier  (URI) 
for  the  schema.  Conflicts  can  appear  when  an  XML  schema  imports  another  XML  schema  (the 
modularity  principle).  For  example,  both  TMATS  and  MDL  include  a  representation  of  a 
measurement.  When  creating  an  integrated  schema  that  includes  elements  of  both  TMATS  and 
MDL,  it  is  necessary  to  have  a  way  to  distinguish  the  TMATS  measurement  from  the  MDL 
measurement.  This  is  done  using  namespaces. 

Namespaces  fully  qualify  the  types  or  elements  within  a  schema  or  instance  document 
using  the  syntax  namespace: SchemaType  or  namespace: elementName.  For  example,  the 
namespace  of  the  TMATS  G  Group  is  http://www.wsmr.army.mil/RCCsite/Documents/106- 
1 5_Tel  em etry  S tan dards/Tm at s G .  The  fully  qualified  name  of  the  DataLinkType  schema  type  is 
http://www.wsmr.army.mil/RCCsite/Documents/106- 

1 5_TelemetryStandards/TmatsG:  DataLinkType.  This  is  an  unwieldy  way  to  reference  a  type  or 
element,  so  the  XML  schema  provides  the  prefix  concept  as  a  way  to  short-hand  the  namespace. 
If  the  user  defines  the  TMATS  G  Group  namespace  prefix  as  TmatsG,  then  the  fully  qualified 
reference  to  the  DataLinkType  becomes  TmatsG:DataLinkType.  In  an  XML  schema, 
namespaces  are  defined  by  the  xmlns  attribute  in  the  top-level  element  and  followed  by  the 
element  prefix. 

Figure  1 1  shows  a  root  element  from  a  TMATS  XML  file.  The  attributes  in  the  top-level 
Tmats:Tmats  element  define  the  namespace  prefixes  for  the  instance  document.  For  example, 
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the  attribute  xmlns:Common  defines  the  namespace  prefix  for  the  TMATS  Common  Types 
schema. 


zl  XML 


Xm'3fe;Tmats 


1 06-1 3 

=  xmlnsiTmafe 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Te  le  metry ‘HiS  0  Sta  nd  a  rds/T  mats 

=  xmlns:B 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Te  le  metry%2  0  Sta  nd  a  rds/T  mats  B 

=  xmlnsiC 

http://  w  w  w.  wsmr.  a  rmy.  mil/RC  Cs  ite/D  d  cu  me  nts/1 06-1 3  JTele  metry1 %2  0  Sta  nd  a  rds/T mats  C 

!=  xmlnsiCojmjTio/T 

http://www.wsmr.army.miI/RCCsite/Documents/1 06-1 3_Telemetry%20Standar£ls/TmatsCommon  | 

=  xmlnsiD 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Tele metry1 %2  0  Sta  nd  a  rdsjT matsD 

=  xmlns:G 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Te  le  metry ‘tfiS  0  Sta  nd  a  rds/T matsG 

=  xmlnsitf 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Te  le  metry1 ft  20  Sta  nd  a  rds/T  mats  H 

=  xmlnsnW 

http:// w  w  w.  wsmr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Telemetry 1 %2  0  Sta  nd  a  rds/T  mats  M 

=  xmlns:P 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RC  Cs  ite/D  d  cu  me  nts/1 06-1 3¥e  le  metry1 %2  0  Sta  nd  a  rds/T  mats  P 

=  xmlns:R 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Te  le  metry  ^20  Sta  nd  a  rds/T mats  R 

5  xmlnsiS 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Tele  metry1 %2  0  Sta  nd  a  rds/T  mats  S 

=  xmlns:T 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Te  le  metry 0  Sta  nd  a  rds/T  matsT 

=  xmlns:V 

http:// w  w  w.  wsmr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Tele  metry  ^20  Sta  nd  a  rds/T  mats  V 

=  xm  Insure/ 

http:// w  w  w.  w3.  d  rg/2  0  0 1  /XM  LS  ch  e  ma-insta  n  ce 

=  jfs/;s€hemaLoca... 

http:// w  w  w.  ws  mr.  a  rmy.  mil/RCCs  ite/D  d  cu  me  nts/1 06-1 3 Te  le  metry1 %2  0  Sta  nd  a  rdsjT  mats  .  A.  AT  mats  .xsd 

O  G:T  mats  File  Name 

GTmatsFileName 

7i  G  .‘Data  Source  ype-RF 


Figure  11.  TMATS  XML  Example  Root  Element,  Prefixes,  and 

Namespaces 


Figure  12  shows  how  namespace  prefixes  are  used  in  a  snippet  of  a  TMATS  XML 
instance  document.  Each  element  in  the  file  includes  the  respective  namespace  prefix  so  that 
there  is  no  ambiguity  about  the  source  of  the  element.  For  example,  the  TMATS  data  source  is 
defined  in  the  G  group,  so  its  namespace  prefix  is  G  (G:DataSource).  Navigating  down  through 
the  data  source  element,  we  eventually  come  to  an  element  from  a  different  namespace  for  the 
PCM  measurements  element  defined  in  the  P  group  (P:PCMMeasurements). 


Namespace  prefixes  in  XML  should  be  short  and  contain  only  lower-case  letters  (Google 
2008).  Child  elements  with  the  same  prefix  are  associated  with  namespaces  defined  for  parent 
elements.  Namespace  prefixes  should  not  be  used  in  attribute  names  since  it  can  make  the 
namespaces  difficult  to  read  (this  is  achieved  by  setting  attributeFormDefault=unqualified, 
described  below). 

Namespace  names  should  be  URIs  that  preferably  resolve  to  an  actual  URI.  The 
namespace  should  have  some  indication  of  the  version  to  which  the  schema  refers.  For  example, 
the  root  IHAL  namespace  is  http://www.wsmr.army.mil/RCCsite/Documents/106- 
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1 5_Tel  em etry S tan dards/i h a  1 ,  where  the  version  is  given  by  “106-15_Telemetry  Standards.” 
Namespaces  must  not  be  changed  unless  there  is  significant  change  to  the  referred  schema. 
Changing  a  namespace  has  significant  effects  on  all  schemas  that  refer  to  it. 

There  is  some  flexibility  in  how  namespace  prefixes  are  used  in  the  context  of  local 
elements  and  attributes  only.  Global  elements  always  include  namespace  prefixes.  The  designer 
may  not  want  XML  instance  documents  to  show  the  namespace  prefix  for  local  elements  and 
attributes  for  a  variety  of  reasons  (our  best  practice  is  to  show  namespace  prefixes  for  elements 
but  not  attributes).  This  is  done  by  specifying  the  element  and  attribute  form  qualification  in  the 
schema  definition  using  the  attributeFormDefault  and  elementFormDefault  attributes, 
respectively.11  We  illustrate  these  concepts  using  three  cases:  unqualified  elements  and 
attributes,  qualified  elements  and  attributes,  and  qualified  elements  and  unqualified  attributes. 

Figure  13  shows  an  example  schema  definition  for  unqualified  attributes  and  elements. 
Note  that  the  elementFormDefault  and  attributeFormDefault  attributes  are  both  set  to 
“unqualified.”  Note  also  that  there  are  three  global  elements  defined:  MeasurementList, 
Measurement,  and  PCMMeasurements. 


XML 

{!■■  Comment 

Example  schema  to  illustrate  qualified  /  unqualified 
elements  and  attributes  that  is  based  an  a  highlight 
simplified  versian  af  the  TMATS  schema.  This  schema 
represents  the  D  Crcup  schema  with  qualified  attributes 

and  elements., 

s  chema 

—  xml  ns 

http : // www   w3  □ r g/ 2001 /XML  S  chema 

—  xmlns : D 

http  :  /  /xml  s  t  y  1  e  guide   □  r g/D 

—  targetHaiaes  .  .  . 

http : / /xml s  t  y 1 egui de . □ r g/D 

el  ement  Form  .  .  . 

unqualified  1 

•attributeFo . . . 

unqualified  1 

Zl  coMplexType  uame=Me  a  sur  extent  Lis  tType 

Zl  complexTyp-e  neme=Me  a  sur  ement-T  yp  e 

tJ  element  name=Measur ementl  ist  type=D: Me  a  sur  ementli s tT  ype 

Zl  element  name=Measurement  t  yp  e=D ::  Me  a  sur  ementT  yp  e 

Zl  element  name=ECMMe  a  sur  ement  s  t  yp  e=D : PCMMe  a  sur  ement  sT  ype 

complexType  name=ECMMe  a  sur  ement  sT  yp  e 

Figure  13.  Example  Schema  with  Unqualified  Elements  and  Attributes 


Figure  14  shows  an  example  instance  document  snippet  that  conforms  to  the  schema 
above.  Note  that  the  global  elements  (PCMMeasurements,  MeasurementList,  and  Measurement) 
are  qualified  with  a  namespace  prefix  (D:PCMMeasurements,  D:MeasurementList,  and 
D: Measurement)  since  the  element  qualification  does  not  apply  to  global  elements.  Neither  the 
attributes  (ID)  nor  the  local  elements  (Name  and  Parity  under  the  D:Measurement  element)  are 
qualified  with  a  prefix. 


11  W3Schools.  XML  Schema  Element,  n.d.  May  be  superseded  by  update.  Retrieved  22  July  2015.  Available  at 
http://www.w3schools.com/schema/el  schema.asp. 
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M  D: 


PCUMeasurement s 


A 

D : Measurement  Li s  t 

— 

ID 

MI-1 

a 

D :  Measurement 

5  ID 

M-l 

{}  Name 

Measurement  #1 

O  Parity 

EVEN 

Figure  14.  Example  Instance  Snippet  with  Unqualified  Elements  and 

Attributes 


Figure  15  shows  an  example  instance  document  snippet  that  conforms  to  the  schema 
above  with  the  modification  that  both  elements  and  attributes  are  qualified.  Both  the  attributes 
(D:ID)  and  the  local  elements  (D:Name  and  D:Parity  under  the  D:Measurement  element)  are 
qualified  with  a  prefix. 


a 

D :  PCMMeasurement  s 

a 

D :  Measurement  List 

S  D:  ID 

MI-1 

A 

D :  Measurement 

=  D:  ID 

M-l 

{}  I? ."Name 

Measurement  £1 

O  D:  Parity 

EVEN 

Figure  15.  Example  Instance  Snippet  with  Qualified  Elements  and 

Attributes 


Figure  16  shows  an  example  instance  document  snippet  that  conforms  to  the  schema 
above  with  the  modification  that  the  elements  are  qualified  and  attributes  are  unqualified.  The 
attributes  (ID)  are  not  qualified  with  a  prefix;  the  local  elements  (D:Name  and  D:Parity  under  the 
D:Measurement  element)  are  qualified  with  a  prefix. 


A 

D  :  PCMM  e  a  s  u  r  ern  e  n  t  s 

A 

D :  Me  asur  ement  Li s  t 

=  ID 

MI-1 

D :  Measurement 

=  ID 

M-l 

{}  D : Name 

Measurement  £1 

f }  D:  Parity 

EVEN 

Figure  16.  Example  Instance  Snippet  with  Qualified  Elements  and 
Unqualified  Attributes 


The  rationale  behind  the  best  practice  for  qualified  elements  and  unqualified  attributes  is 
the  following. 

•  Qualified  elements  make  the  namespace  where  the  element  is  defined  explicit.  Since 
global  elements  are  always  qualified,  it  might  be  confusing  to  the  user  of  the  schema  to 
see  some  elements  qualified  and  some  not. 
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•  Unqualified  attributes  make  the  attribute  names  more  concise.  Since  there  is  no 
distinction  between  global  and  local  attributes,  there  is  no  possible  confusion  as  in  the 
case  for  elements. 

4.5  Global  vs.  Local  Types 

The  following  is  a  summary  of  the  best  practices  for  global  and  local  types  (Stephenson 

2004). 

•  Elements  should  be  defined  globally. 

•  Complex  and  simple  types  shall  always  be  defined  globally. 

A  component  (element,  complex  type,  or  simple  type)  is  global  if  it  is  an  immediate  child 
of  the  top-level  <schema/>  element;  it  is  local  if  it  is  nested  within  another  component.12  There 
are  three  patterns  that  are  commonly  used  to  illustrate  the  global  vs.  local  decision,  as  described 
in  the  following  sub-sections.  Our  best  practice  is  to  use  the  Venetian  Blind  pattern. 


4.5.1  Russian  Doll  Design 


In  this  pattern,  the  schema  structure  mirrors  the  element  structure;  that  is,  the  schema 
components  are  defined  locally  to  the  component  that  it  is  contained  in.  This  is  the  “local”  end 
of  the  global  vs.  local  type  spectrum.  Figure  17  and  Figure  18  illustrate  this  pattern  for  TMATS 
measurements  from  an  early  version  of  the  TMATS  XML  schema  (Tmats_05-2007.xsd).  Note 
that  the  elements  and  the  structure  of  the  Measurement  location  element  are  defined  local  to  the 
Measurement  element.  Figure  17  graphically  illustrates  the  Russian  Doll  design.  Figure  18 
illustrates  the  Russian  Doll  design  in  XML  text. 


!  traats  :  tie  asureraent  F^l  — 

r - -  - 

0 .  .oc 


EB  attributes 


' traats  Length  | 
traats  Parity  | 


MN1 


traats  Pari tyTrans  ferOrder  i 


MN2 

traats  ble  asureraent  T  rans  ferOrder  ' 


MN3 


traats  Measurement  Lo  cat  ion  E 


1..® 


I 


Repeat  however  many  time  are  required  to 
com pieteJy  describe  tSuis  measurement's 
locations  in  the  fra  me. 


Figure  17.  Graphical  Illustration  of  Russian  Doll  Design  -  TMATS 

Measurement 


12  Costello,  et  al.  “Global  versus  Local”,  in  XML  Schemas:  Best  Practices.  1  November  2006.  Retrieved  22  July 
2015.  Available  at  http://www.xfront.com/GlobalVersusLocal.html. 
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<x  s  :  e  1  enter.  t  n ame = "Me  a  sur  emer.  t rr  minO  c  cu  r  s = rr  0 rr  maxG  c  cu  r  s = "unb  collided rr  > 

<X3 :  annotation 

<xs : document at ion>MN</xs : documentation^ 

< /x  3 : ann o  t  a  t i on> 

<xs : comp lexType> 

<X3 :  3equer.ce> 

<xs : element  n ame =rr Length"  type="xs  ipositivelntegex"  minOccur3=rrOrr/> 

<X3  :  element  name=ri  Parity"  default=" Default "  minGccurs="0 "> 

<X3  :  element  name=  "  ParityTrar.3f erCrdei "  default=  "Default "  mln0ccur3="0"> 

<X3  :  element  name="MeasurementTransf  erOrder ri  def  ault="Def  ault "  minCccurs="0"> 

<X3  :  element  name="  Measurement  Location"  maxOc  cur  s= "unbounded1^ 

<xs  :  annotation > 

<xs : document at ion>Repeat  however  many  time  are  required  to 
completely  describe  this  measurement's  locations  in  the 
f r  ame F</xs : document at ion> 

<[/x3 :  annotations 
<xs : complex! ype> 

<xs :  sequen.ce> 

<xs : element  name =" Measurement Fragments"  maxOccurs="3"> 

</xs :  seqirer.ce> 

</xs : complex! ype> 

</x3 : element> 

</xs : sequence> 

<xs  :  attribute  r ame = "Name"  t\ipe="xs  :  string"  use="required"/> 

< /x s  :  c omp  1  exT \ipe> 

</xs : elemert> 

Figure  18.  Textual  Illustration  of  Russian  Doll  Design  -  TMATS 

Measurement 

Characteristics  of  the  Russian  Doll  design  include  the  following  (Costello  et  al.  2006). 

•  Opaque  -  the  content  of  each  component  is  opaque  to  other  parts  of  the  schema  and 
cannot  be  reused. 

•  Localized  scope  -  if  the  schema  has  a  default  element  form  unqualified,  then  the 
namespaces  of  the  contained  elements  are  hidden;  this  makes  namespace  management 
easier. 

•  Compact  -  everything  is  bundled  together. 

•  Decoupled  -  changes  to  the  component  will  have  limited  impact;  the  contents  can  be 
changed  with  minimal  (if  any)  impact  to  other  parts  of  the  schema  or  other  schemas  that 
might  include  it. 

•  Cohesive  -  all  data  is  grouped  into  self-contained  components. 

The  Russian  Doll  design  pattern  hides  namespace  complexities  and  limits  or  prohibits 

reuse. 

4.5.2  Salami  Slice  Design 

In  this  pattern,  the  schema  is  disassembled  into  individual  components.  Each  component 
is  defined  as  an  element  declaration  and  then  assembled  together  as  needed.  This  is  the  “global” 
end  of  the  global  vs.  local  type  spectrum.  Figure  19  and  Figure  20  illustrate  this  pattern  for  the 
IHAL  instrumentation  graph.  Note  that  the  instrumentation  graph  element  is  global,  the 
instrumentation  graph  type  is  global,  and  the  sub-elements  instrument  use  and  connection  are 
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references  to  globally  defined  elements.  Figure  19  graphically  illustrates  the  Salami  Slice 
design.  Figure  20  illustrates  the  Salami  Slice  design  in  XML  text. 


Figure  19.  Graphical  Illustration  of  Salami  Slice  Design  -  IHAL 
Instrumentation  Graph 


<x 3  :  e  1  enter,  t  r.  ante  = "  ins  t  imaent  a  t  i  onGr  aph rr  t  yp  e = "  iha  1  ins  t  gr  aph :  Ins  t  r umen t  a  t  i  onGr  aphT  yp  e ri  > 

<xs  :  anno  t  a  t  i  on> 

<xs : document at ion> A  set  of  interconnected  instruments, 
such  as  the  airborne  system,  or  the  ground  system. 

< /xs : do  cumen  t  a  t i on> 

</xs: ann otation> 

</xs : element> 

<x  s :  c  omp  1  exT  yp  e  n  ante = "  Ins  t  rument  a  t  i  onGr  aphT  yp  e rr  > 

<xs :  seqirer.ce> 

<xs  :  element  name=  "description17  t yp e =rr iha X common :  DescriptionType "  minOccurs=rrO  rr/> 

<xs: element  r  e  f ="  ihal  ins  t  us  e  :  instrument  Use"  minOccurs=rrOrr  maxOccurs="unbounded"/> 

<xs  :  element  ref="ihalinst graph:  connection"  minOccurs="Orr  maxOccurs=rrunboundedrr/> 

</x3 : sequence> 

<xs  :  attribute  ref =" iha  1  common  :  IDrr  use=rrrequiredrT/> 

<x,s  :  attribute  ref =ri  ihalcommor. :  ihal Version"/ > 

</xs : complex! ype> 

Figure  20.  Textual  Illustration  of  Salami  Slice  Design  -  IHAL 
Instrumentation  Graph 

Characteristics  of  the  Salami  Slice  design  include  the  following  (Costello  et  al.  2006). 

•  Transparent  -  the  content  of  each  component  is  visible  to  other  parts  of  the  schema  and 
can  be  reused. 

•  Global  scope  -  regardless  of  the  element  form  default  value,  the  namespaces  of  the 
components  will  be  visible  in  instance  documents. 

•  Verbose  -  every  component  is  visible. 

•  Coupled  -  changes  to  the  component(s)  can  impact  other  components  that  use  it;  the 
components  are  interconnected. 

•  Cohesive  -  all  data  is  grouped  into  self-contained  components. 

The  Salami  Slice  design  pattern  facilitates  component  reuse  of  the  maximum  extent,  but 
requires  coordination  and  careful  thought  in  the  naming  and  design  of  global  elements  and  types. 
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4.5.3  Venetian  Blind  Design 

In  this  pattern,  the  schema  design  consists  of  components  (like  the  Salami  Slice  design), 
but  elements  can  be  defined  locally.  This  design  maximizes  reuse  and  the  potential  for  local 
namespace  hiding.  Figure  21  and  Figure  22  illustrate  this  pattern  for  MDL  measurements.  Note 
that  the  elements  of  these  types  are  defined  local  to  the  enclosing  structure.  Figure  21 
graphically  illustrates  the  Venetian  Blind  design.  Figure  22  illustrates  the  Venetian  Blind  design 
in  XML  text. 


M  ea  s  Li  re  m  e  ntsTy  p  e 

r--!- Readonly  ; 

-j  Measurements  [j— ~ ~i=  Owner  ! 

- 

Lr-;  Measurement  ^fTsTH+l 
!  0  oo 

L _ 


t 


Figure  21.  Graphical  Illustration  of  Venetian  Blind  Design  -  MDL 

Measurements 


<xsd:complexType  name=l!MeasurementsType"> 

<xsd:annotation> 

<xsd:sequence> 

<xsd:element  name=MReadOnlyM  type- 'xsdibodean11  default- 'false"  minOccurs-r07> 

<xsd:element  name=,,0wner"  type="xsd:tokenM  min0ccurs="O7> 

<xsd:element  name=MMeasurement"  type="MeasurementType"  minOccurs="Q"  max0ccurs="unbounded7> 
</xsd:sequence> 

</xsd  :;c  o  m  pi  exT y  pe  > 

Figure  22.  Graphical  Illustration  of  Venetian  Blind  Design  -  MDL 

Measurements 

Characteristics  of  the  Venetian  Blind  design  include  the  following. 

•  Maximum  reuse  -  type  definitions  are  defined  globally. 

•  Maximum  namespace  hiding  -  element  declarations  are  enclosed  within  type  definitions. 

•  Easy  exposure  switching  -  the  elementFormDefault  attribute  controls  namespace 
visibility. 

•  Coupled  -  global  type  definitions  generate  interconnectedness. 

•  Cohesive  -  all  data  is  grouped  into  self-contained  components. 

Following  the  Venetian  Blind  design,  the  following  guidelines  shall  be  followed 
(Costello  et  al.  2006). 

•  Use  global  type  definitions  as  the  main  form  of  component  reuse. 

•  Global  element  definitions  are  encouraged  but  not  required. 

4.6  Attribute  Guidelines 

The  following  guidelines  apply  to  XML  attributes  (Google  2008). 
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•  An  ordering  of  the  attributes  defined  for  an  element  in  an  instance  document  shall  not  be 
assumed  since  XML  parsers  may  not  enforce  this. 

•  Attributes  should  be  used  for  IDs  and  IDREFs  only. 

•  Attributes  that  might  contain  a  value  with  a  line  break  shall  not  be  used  in  an  instance 
document  since  XML  parsers  might  not  process  this  correctly. 

•  A  difference  between  single  or  double  quotes  around  the  attribute  value  in  an  instance 
document  shall  not  be  assumed  since  most  XML  parsers  treat  them  the  same. 

4.7  Value  Guidelines 

The  following  guidelines  apply  to  XML  element  and  attribute  values  (Google  2008). 

•  Numeric  values  shall  be  32-bit  signed  integers  (xsd:int),  64-bit  signed  integers  (xsddong), 
or  64-bit  IEEE  doubles  (xsd:double),  all  expressed  in  base  10. 

•  Boolean  values  shall  be  typed  to  xsd:Boolean  and  only  have  the  values  true  and  false. 

•  Dates  shall  be  represented  in  RFC  3339  format  (xsd:dateTime).13  The  UTC  shall  be  used 
rather  than  local  times. 

4.8  XML  Instance  Document  Guidelines 

The  following  guidelines  apply  to  XML  instance  documents  (Google  2008). 

•  UTF-8  character  encoding  shall  be  used. 

•  Namespaces  shall  be  declared  in  the  root  element  of  the  document. 

•  Namespace  URIs  shall  be  mapped  to  prefixes  one  time  in  the  document. 

•  Standard  namespaces  prefixes  for  standard  URIs  shall  be  used. 

•  Standard  namespace  prefixes  for  IRIG  106  schemas  shall  be  used. 

o  tmats,  tmatsa,  tmatsb,  etc.  for  the  TMATS  schema,  mdl  for  the  MDL  schema,  etc. 

•  Redundant  whitespace  in  component  tags  should  be  minimized. 

•  CDATA  shall  not  be  used. 

•  Comments  shall  be  written  to  support  automated  documentation  generation. 

4.9  Guideline  for  Using  Attributes  or  Elements 

The  following  guideline  applies  for  when  to  use  an  attribute  or  element  to  represent  a 
piece  of  information  (Google  2008).  Attributes  are  more  restrictive  than  elements,  so  an  all¬ 
element  design  is  the  simplest.  Elements  use  more  memory  than  attributes  internally  and  make 
the  XML  file  itself  larger  because  of  the  use  of  begin  and  end  tags.  In  some  programming 
languages  or  libraries,  the  processing  of  attributes  and  elements  is  very  different,  so  there  could 


13  Internet  Engineering  Task  Force.  Date  and  Time  on  the  Internet:  Timestamps.  RFC  3339.  July  2002.  May  be 
superseded  by  update.  Retrieved  16  July  2015.  Available  at  http://www.rfc-editor.org/rfc/pdfrfc/rfc3339.txt.pdf. 
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be  performance  implications  to  the  choice  of  attributes  vs.  elements.  Take  into  consideration  the 
processing  of  the  XML  instance  documents  when  making  this  decision. 

The  specific  guideline  for  attributes  is  to  use  them  only  if  the  data  being  modeled  is  an  ID 
or  an  IDREF  to  some  other  piece  of  data  (Google  2008).  This  is  not  a  hard  and  fast  rule,  but 
should  be  discussed  and  reviewed  at  design  time. 

4.10  Other  Guidelines 

The  following  other  guidelines  apply. 

•  Binary  data  shall  not  be  used. 

•  An  ID  shall  only  be  used  as  a  reference  for  an  IDREF.14 

•  Namespaces  shall  contain  a  version. 

•  Schemas  shall  be  compatible  with  the  following  libraries:  XML  Beans15,  JAXB16. 

5.  Illustration  of  Use  of  Guidelines 

This  section  illustrates  the  use  of  the  guidelines  in  a  semi-realistic  modeling  situation. 

The  modeling  problem  is  as  follows:  define  an  XML  schema  using  the  best  practices  to  model 
T&E  instrumentation  hardware  including  data  acquisition  units  (DAUs),  bus  controllers, 
recorders,  signal  conditioning  cards,  and  measurements.  The  intent  of  this  exercise  is  to 
illustrate  the  best  practices  and  not  necessarily  model  a  real  T&E  scenario. 

The  modeling  requirements  are  as  follows. 

•  DAUs  are  defined  by  a  name,  description,  bus  type,  and  recorder  type. 

•  Bus  controllers  are  defined  by  a  name,  description,  and  bus  type. 

•  Recorders  are  defined  by  a  name,  description,  and  recorder  type. 

•  Signal  conditioning  cards  are  defined  by  a  name,  description,  and  amplification. 

•  Measurements  are  defined  by  a  name,  description,  and  sample  rate. 

Figure  23  is  a  schema  that  meets  the  requirements  of  the  model,  but  it  violates  several  of 
the  best  practices.  There  is  no  consistent  naming  convention.  There  is  no  reuse  of  common 
structures.  There  is  no  modularity.  We  will  incrementally  modify  this  design  to  illustrate  the 
best  practices. 


14  Dare  Obasanjo.  W3C  XML  Schema  Design  Patterns:  Avoiding  Complexity.  January  2003.  Retrieved  17  July 
2015.  Available  at  http://msdn.microsoft.eom/en-us/librarv/aa468564.aspx#xmlscmavdcmplx  topic!3. 

15  “Welcome  to  XMLBeans.”  The  Apache  XML  Project.  Last  published  15  August  2012.  Retired  23  May  2014. 
http://xmlbeans.apache.org/. 

16  “Project  JAXB.”  Java.net.  Last  published  14  October  2014.  https://iaxb.iava.net/. 
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Figure  23.  Initial  Example  Schema  Design 


Figure  24  shows  the  initial  schema  with  the  naming  convention  applied  to  the  schema 
elements.  The  readability  of  the  schema  is  improved  by  using  the  naming  convention  best 
practice.  This  is  also  an  example  of  the  Russian  Doll  design  pattern. 


Figure  24.  Example  Schema  with  Naming  Convention  Best  Practice 


There  are  still  several  problems  with  this  schema,  such  as:  each  element  is  defined 
locally;  even  though  the  “name”  element  is  used  in  multiple  places,  it  is  defined  in  a  single, 
global  way;  there  is  no  reuse  of  common  structures.  To  remedy  this,  we  create  global  simple 
types  for  names,  descriptions,  bus  types,  etc.,  and  use  those  type  definitions  in  each  of  the 
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structures  in  our  schema.  When  we  do  this,  we  make  sure  that  the  naming  convention  for  types 
is  followed.  Figure  25  shows  the  schema  with  global  simple  types  defined  for  name,  description, 
and  bus  type.  This  modification  promotes  reuse  of  these  types.  With  this  modification,  we 
partially  achieve  the  Venetian  Blind  design  pattern. 

<  f  s  impl  eT vp ft  ue  * n  watfieT ype  n  > 

I  <X3 :  restriction  ba9e="xs:3trLngn> 

l  \  <xa: length  valrae="16"/> 

!  </xa treatrictiGn> 

</ ks i * imp 1 tTyp  e> 

;  SiinplftType  n«i5e="De3cript±OFjTypft,,> 

I  <xs: restriction  tase=r,xs  :  stringrT> 

1  |  <xa:  length  value=MOrr/> 

|  </xsj restriction^ 

</xst3XJSpleType> 

<x  s  :  a  inipl  eTyp  e  n ame  = r| Bu sTyp e ,f > 

<  its :  r  e  3 1  r  ie t  i  on  ba  s  e=  "  xa  :  s  t r ing  "  > 
l  <X3 : enumeration  ^alus=nMIL-STD  15531T/> 

j  <x3:entiaeEation  value=hARINC  129N/> 

</xs : reatr ictiom> 

</ xa :  s  i  Trip  1  eType> 

Figure  25.  Example  Schema  with  Global  Types 


<xs  :  e  1  eirie  nt  n  arce  =  "  name  r  t  ype  =  M  Name! ype rr  /  > 

<xs  :  element  name=  **  da  script  ion  h  type=hDescripcionTypeft/> 
<xs  :eleiTient  name  =  "bu3Type"  type=,lBusT^pe’"/> 

<xs :  e  1  erne nt  n ame = n  recor  de  rTyp e  "  t yp  e = 11  z  e  co  rde  r  -t yp  e  "  /> 


While  the  modifications  made  so  far  improve  the  initial  design  in  several  ways,  there  is 
still  opportunity  to  improve  modularity  and  achieve  a  fully  Venetian  Blind  design  pattern.  In  the 
schema  as  it  now  is,  the  DAU,  bus  controller,  recorder,  and  air  speed  measurement  share  a  name 
and  description  structure.  To  achieve  a  more  modular  schema,  we  create  a 
GenericInstrumentType  complex  type  that  consists  of  a  name  and  a  description  and  extend  this 
GenericInstrumentType  for  the  DAU,  bus  controller,  recorder,  and  measurement  types.  Figure 
26  shows  this  schema  modification. 


Figure  27  shows  the  schema  with  all  the  modifications.  This  is  a  Venetian  Blind  design 
pattern  since  some  elements  are  local  (sample  rate  element  of  the  air  speed  measurement)  and 
some  are  global  (bus  type  and  recorder  type  elements  of  the  DAU).  If  all  elements  were  global, 
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the  schema  would  be  an  instance  of  the  Salami  Slice  design  pattern.  The  Venetian  Blind  design 
pattern  should  be  used  since  it  may  not  be  necessary  to  make  all  elements  global;  for  example, 
since  the  sample  rate  is  only  used  in  the  air  speed  measurement  it  is  not  necessary  to  make  this 
global  (it  is  not  shared  by  multiple  elements). 


Figure  27.  Venetian  Blind  Design  Pattern 


The  modularity  of  our  schema  so  far  does  not  allow  us  to  use  these  type  definitions  in 
other  schemas.  We  would  like  to  be  able  to  use  the  GenericInstrumentType  definition  in 
multiple  schemas.  To  use  the  structures  in  a  schema  (the  imported  schema )  in  some  other 
schema  (the  importing  schema),  we  must  do  the  following. 

1 .  Uniquely  identify  the  imported  schema  by  assigning  a  namespace  to  that  schema;  since 
namespaces  can  be  long,  we  associate  the  schema  with  a  namespace  prefix. 

2.  Disambiguate  the  imported  and  importing  schema  elements  by  qualifying  the  schema 
attributes,  elements,  and  types;  this  is  done  using  the  namespace  prefixes. 

3.  Import  the  imported  schema  into  the  importing  schema  and  use  the  structures  of  the 
imported  schema  in  the  importing  schema. 

To  illustrate  this,  we  will  separate  out  the  GenericInstrumentType  definition  into  its  own 
schema  and  use  it  in  a  new  card  schema.  Figure  28  shows  the  GenericInstrumentType  schema. 
The  type  definition  is  moved  into  its  own  schema  file  and  assigned  the  namespace 
http://www.rcc.org/generic  in  the  XML  schema  header  (attribute  targetNamespace)  and  assigned 
a  prefix  “generic”  (attribute  xmlns:generic).  In  the  schema  definition,  note  that  the  name  and 
description  elements  are  associated  with  the  generic  namespace  to  remove  the  possibility  of  any 
ambiguity. 
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|  <xs : schema 

xrclns  :  xs=”ht-tp :  //www.  w3 .  org/20Ql/XML5cheir.a" 
targetNamespace^http : //www. rcc . org/ generic” 
xnans:generic="http://www. rcc. org/generic" 
element  FormDef  aults=”quallf  led" 
attnbuteFormDef  ault*”unqualifieci”> 


m generic : name 

_  generic : description 
£ - 

Figure  28.  Generic  Instrument  Type  Schema 


(cenerielnatrumentType  l~l~~(  •••  JEI~ 


A  card  schema  can  now  be  created  that  imports  the  GenericInstrumentType  schema  and 
defines  card  types  based  on  the  GenericInstrumentType  definition.  Figure  29  shows  the  signal 
conditioning  card  schema.  A  new  schema  file  is  created  and  assigned  the  namespace 
http://www.rcc.org/card  in  the  XML  schema  header  (attribute  targetNamespace)  and  assigned  a 
prefix  “card”  (attribute  xmlns:card).  The  XML  schema  header  also  includes  the  definition  of  the 
generic  namespace  (attribute  xmlns:generic).  The  type  for  a  signal  conditioning  card  extends  the 
generic  instrument  type  by  adding  an  amplification  element.  The  generic  instrument  schema  is 
imported  using  the  import  statement  with  the  location  and  namespace  of  the  imported  schema. 
Note  that  the  generic  instrument  type  name  and  description  are  associated  with  the  “generic” 
namespace  prefix  and  the  amplification  element  is  associated  with  the  “card”  prefix  to  remove 
any  ambiguity. 


<X3 ; schema 

xmlr.3  :x3=T'hctp :  //www. w3 .  Qrg/2001/XHL3cheman 
xmlna  :  genez±c="littp  :  //ww.  rcc  .  org/generic" 
xmins :  card-'^http : //www,  rcc.  org/ card71 
T:arcecNarf.espaee",'hctp :  //www.  rcc  .org/ card" 
elemeri’cFormDefault="<juolifietJri 
a  t  tr  ibu  t  e  F  □  rnaDe  f  a  u  1 1 = ,run  qua  lift  ed Fr  > 

<xs: import 

name  apace  -  *  http :  /  /  www  .rec.org/  gene  r  ie rr 
schema Lee at  ion*  "Generic  Instrument  Schema  +  xsdFt/> 


ruipic  :C«iBrlci^itrnaant?jpf  T.Grn  = 


^Si.gnj.ltQHgLi  t  icmitijgCard.typ*  jyl- 


|  ’per.-'  ric  :  qoj 


&  : 


igeneric.ded'cription 


HEW  ampLifi 


fic-ation 


Figure  29.  Signal  Conditioning  Card  Type  Schema 
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